fix(tests): isolate fixtures from codemod rewrites and bump Windows debug stack#613
Conversation
…ebug stack Copy fixtures into a per-test temp dir before invoking ado-aw compile so the pool_object_form codemod cannot race-rewrite tests/fixtures/*.md under parallel cargo test, which was tripping the lost-update guard with 'source file ... changed during compilation' on CI. Also add .cargo/config.toml setting /STACK:8388608 on Windows MSVC to match the Linux/macOS 8 MiB default. Debug builds of ado-aw compile overflow the 1 MiB Windows main-thread stack because #[tokio::main] polls the top-level future on main and the deeply-nested async fns produce very large unoptimised state machines. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
🔍 Rust PR ReviewSummary: Looks good — two targeted, correct fixes with no issues found. Findings✅ What Looks Good
|
1 participant
Summary
Two surgical fixes for the failing
test_1es_compiled_output_no_unreplaced_markersCI test, plus a Windows-only build-config fix discovered while reproducing it.1. Fix codemod race in compile-fixture tests (
tests/compiler_tests.rs)CI error:
Root cause. The
pool_object_formcodemod (introduced in 0.30.0) fires ontarget: 1esfixtures lackingpool:, injectingpool: { name: AZS-1ES-L-MMS-ubuntu-22.04 }and rewriting the source on disk.cargo testruns in parallel, so multiple tests targeting the same fixture all snapshot the original SHA and race to write back — whichever loses trips the lost-update guard insrc/compile/mod.rs:305-310.Fix. Copy each fixture into a per-test temp dir before invoking the compiler. Codemods may still fire (harmless on the temp copy) but the canonical fixture under
tests/fixtures/is never mutated and parallel tests cannot race.Two edits:
test_1es_compiled_output_no_unreplaced_markers(the failing test): now copies1es-test-agent.mdinto the temp dir.compile_fixture_with_flagshelper (used by ~12 other tests): same pattern.tests/bash_lint_tests.rswas already doing this correctly. Other inline compile invocations incompiler_tests.rsdon't target the 1ES fixtures that trigger the codemod.2. Fix Windows debug-build stack overflow (
.cargo/config.toml)When reproducing the CI failure locally on Windows, the compile crashed with
thread 'main' has overflowed its stackbefore the codemod logic ever ran — a separate, pre-existing issue.Root cause.
#[tokio::main]polls the top-level future on the main thread. Debug builds produce very large async state machines (no optimisation collapses them), and the deeply-nestedasync fns inado-aw compileexceed Windows' default 1 MiB main-thread stack. Linux/macOS default to 8 MiB and were unaffected. Release builds work everywhere because optimisation shrinks the state machines.Fix. New
.cargo/config.tomladds/STACK:8388608(8 MiB, matching Linux) via a linker flag gated tocfg(all(windows, target_env = "msvc")). Linux and macOS builds are untouched.Test plan
cargo test— full suite passes on Windows (1587 unit + 91 compiler + 0 failures across all test binaries). Before the fix,test_1es_compiled_output_no_unreplaced_markersfailed on Windows (stack overflow) and on Linux CI (codemod race).ado-aw compile tests/fixtures/1es-test-agent.mdwith the freshly-rebuilt debug binary on Windows — no stack overflow, codemod fires on the temp copy as expected.tests/fixtures/is no longer mutated by test runs (git statusclean aftercargo test).